Streaming media relates to constant delivery of media by a provider, to be received by and presented to an end-user.
Streaming may be used for any type of information such as data, audio or video, and content such as music, movies, games, closed captioning, stock ticker, real-time text, medical operations, or any other data to be streamed or broadcast. Common environments or applications of streaming media include but are not limited to interactive television information systems such as video on-demand (VoD) providing pre-ready contents or games, and internet television.
Streaming media has become more and more popular due to a number of reasons, including the increased network bandwidth, especially in the last mile, increased access to and commercialization of networks, especially the Internet, and the use of standard protocols and formats, such as TCP/IP, HTTP, and HTML.
A media stream can be streamed either live or on-demand. Live streams are generally provided by a means called “true streaming”, which sends the information without saving the file to a hard disk. On-demand streaming may be provided by a means called progressive streaming or progressive download, which saves the file to a hard disk and then plays it from that location. On-demand streams may be saved to hard disks and servers for extended amounts of time, while the live streams are only generated and available at one time e.g., during an interactive game, a broadcast game or others.
An architecture for live or on-demand services in systems such as but not limited to cable television (CATV) systems may include a plurality of sources, such as files, game servers or others which retrieve or render a sequence of frames; optionally one or more encryption engines, for encrypting the streamed frames; and one or more edge devices, each of which packetizes sub-sets of input streams into a multi program/service transport stream (MPTS) format, modulates each MPTS through a quadrature amplitude modulation (QAM), and transmits the radio frequency (RF) modulated signal to the set top box at the client's premises.
In order to save transmission time, the data may be compressed prior to sending, and decompressed by the client device. The selected type of compression and streaming may be based on the types of the data, the clients and the communication channels.
For example, audio streams may be compressed using an audio codec such as MP3, Vorbis or AAC, while video streams may be compressed using a video codec such as H.264/MPEG-4 or VP8. The stream may be delivered from a streaming server to a streaming client using a transport protocol, such as MMS or RTP. The streaming client may interact with the streaming server using a control protocol, such as MMS or RTSP.
Traditionally, transmitting TV services over IP networks is considered less reliable then transmission over cable network. The reliability of the TV service may be measured by several factors, including but not limited to jitter, delay and packet losses, which may be measured by quantity and/or frequency.
It will be appreciated that the loss of even a single packet may have large impact on the video quality at the subscriber side, for example at the set top box (STB). For example, when H.264/MPEG-4 compression is used, a frame may be expressed relatively to a previous frame, e.g. indicating only the changes from the previous frame. Thus, if a frame is lost, subsequent frames may be useless as well.
Transmitting TV services over IP networks and overcoming lost packets may be done in a number of methods, for example:
Transmission Control Protocol (TCP) streaming is common for VoD services, and used for progressive download, meaning that the content is downloaded very fast to the STB, cached for a period such as a few seconds, after which the contents is played while the continuation content is received behind the scenes. Since the STB may have a large pre-multiplexing buffer, then in the case of lost packets, the TCP protocol will request the server side to re-transmit the lost packet. The server side may also maintain a large buffer of transmitted content, allowing it to resend lost IP packets even after some time has passed since the original transmission time. TCP streaming is generally not useful for Games on Demand (GoD) services since additional buffers may be required at the server side or at the STB, and the delay caused by the round trip can badly affect the user's gaming experience.
User Datagram Protocol (UDP) streaming is mostly common in broadcast services. UDP is generally an unreliable protocol and is vulnerable to lost IP packets. In order to recover lost packets, it is common to have a group of pictures (GOP) of a small size, typically 16-32 frames, which eliminates the lost packet artifacts within 0.5-1 second. Since an I frame (a frame for which no previous frame is required for decoding) requires higher bandwidth, then in order not to increase the delay, it is common to have very large or even unlimited GOP.
ProMpeg Forward Error Correction (FEC) over UDP streaming: Pro-mpeg FEC can be used to recover lost packets on the account of additional bandwidth, typically in the range of 40-60% overhead, by transmitting FEC packets generated by the server side to the STB side. Although the Pro-mpeg FEC method is useful for recovering lost packets, it has three main disadvantages that prohibit it for being used for GoD services. First, the method requires additional band width (BW). If the maximal BW which is limited by the line rate is to be maintained, the additional required BW will be deducted from the transport BW, which mostly consists of video data, resulting in decreasing the video quality. Second, a large delay is added by streaming the FEC packets ahead of the TV content payload. Third, the number of packets that can be recovered is limited, and bursts of lost packets cannot be recovered.